[WinRT] Start exposing Windows Runtime headers to Swift #84669
Conversation
egorzhdan
requested review from
a team,
zoecarver,
beccadax,
ian-twilightcoder,
Xazax-hun,
j-hui,
fahadnayyar,
susmonteiro,
etcwilde,
compnerd,
edymtt and
justice-adams-apple
as code owners
This is a companion to swiftlang/swift#84669.
|
swiftlang/swift-installer-scripts#465 @swift-ci please smoke test |
|
swiftlang/swift-installer-scripts#465 @swift-ci please build toolchain Windows |
This adds an initial Clang modulemap for the WinRT module. The modulemap is injected into the `winrt/` include search path using VFS. For now, the modulemap only exposes a small number of utility headers from WinRT. It will be extended in the future to cover more of the WinRT API surface.
egorzhdan
force-pushed
the
egorzhdan/winrt
branch
from
c47fbeb to
c3074df
Compare
|
swiftlang/swift-installer-scripts#465 @swift-ci please smoke test |
|
swiftlang/swift-installer-scripts#465 @swift-ci please build toolchain Windows |
|
swiftlang/swift-installer-scripts#465 @swift-ci please build toolchain Windows ARM64 |
|
swiftlang/swift-installer-scripts#465 @swift-ci please smoke test Linux |
|
swiftlang/swift-installer-scripts#465 @swift-ci please smoke test macOS |
|
swiftlang/swift-installer-scripts#465 @swift-ci please build toolchain Windows ARM64 |
|
swiftlang/swift-installer-scripts#465 @swift-ci please build toolchain Windows |
how far does this plan on going? will it eventually include all |
| ucrt.modulemap | ||
| winsdk_um.modulemap | ||
| winsdk_shared.modulemap | ||
| WinRT.modulemap |
There was a problem hiding this comment.
winsdk_winrt seems like a more consistent name? it would be ideal to import WinSDK.WinRT as opposed to import WinRT. the latter can cause lots of collisions with other WINMD based projection tools which will generate code in the WinRT module
There was a problem hiding this comment.
Is WinRT considered part of the Win32 SDK? I thought it was a separate parallel piece. The submodule support isn't sufficient to support that in Swift I think? So this will need to be a top-level module.
There was a problem hiding this comment.
there is just the "Windows SDK" . the distinction between Win32 and WinRT are the APIs used. but since the module is called WinSDK it seems appropriate to keep them all together? if WinSDK was named Win32 i would feel differently
There was a problem hiding this comment.
there are other submodules in WinSDK, so that should be fine?
There was a problem hiding this comment.
WinRT can't be a submodule of WinSDK mostly for build performance reasons. WinRT headers are huge, for instance for WinUI headers alone Clang produces a .pcm that is 300MB+ and takes over 10 minutes to precompile on my machine (with weak specs). Clang builds .pcms per top-level module, so all submodules are effectively merged into one. Similarly, Swift merges all submodules into a single module when importing them. That means that for a project that only uses Win32, clang would spend significant time prebuilding WinRT headers, and then Swift would spend time importing WinRT decls into Swift.
For this reason, I'm going to propose splitting WinRT headers into many top-level modules, e.g. having a top-level module WindowsXyz per windows.xyz.*.h. But that is out of scope of this PR ;)
the latter can cause lots of collisions with other WINMD based projection tools which will generate code in the WinRT module
Is WinRT a conventional name for some of the modules that are generated by other tools?
There was a problem hiding this comment.
For this reason, I'm going to propose splitting WinRT headers into many top-level modules, e.g. having a top-level module WindowsXyz per windows.xyz.*.h. But that is out of scope of this PR ;)
Does the fact that namespaces in WinRT can have cyclical dependencies affect this at all?
I think that would be the ideal outcome, yes! However I don't yet have a concrete plan to list every single WinRT header in the modulemap, and I'm not sure if Swift will actually be able to correctly digest all of them. For now I'm mostly interested in WinUI and its dependencies. |
The most interesting WinRT development is done in WindowsAppSDK (with UWP you're limited to the sandbox, which may be ok, but for most it isn't) and those don't ship in the Windows SDK. |
|
I'm curious, why does swift want to go down this route of including windows.* headers from the SDK, as opposed to using a winmd based code generator tool? those headers in the windows SDK aren't really meant for consumption. unless you have plans for neat tricks, writing Swift from those headers would feel very much like writing WRL in C++ |
This adds an initial Clang modulemap for the WinRT module. The modulemap is injected into the
winrt/include search path using VFS.For now, the modulemap only exposes a small number of utility headers from WinRT. It will be extended in the future to cover more of the WinRT API surface.